OperatorHub Release CLI / Moving OperatorHub release to Buildkite #6281
Conversation
Adding vault option for easier usage. move vault to container command move single bundle command to push + publish commands make create-pr separate command
adding prefight additional fixes
Fix issues in create-pr tooling.
code cleanup
un-export funcs Adjust some comments
removal of 'all' command. Removing preflight
move container prerune to persistent to ensure sub-commands also have it run cleanup readme.
flags validation update. attempting to hide root flags on sub-commands.
Cleanup readme
Make vault secrets default properly.
Update readme Update some env var comments.
naemono
added
>enhancement
Signed-off-by: Michael Montgomery <[email protected]>
Update example command for generate-manifests. Signed-off-by: Michael Montgomery <[email protected]>
Signed-off-by: Michael Montgomery <[email protected]>
Signed-off-by: Michael Montgomery <[email protected]>
Signed-off-by: Michael Montgomery <[email protected]>
There was a problem hiding this comment.
Maybe I miss something but as discussed in #6281 (comment), I think we shouldn't duplicate what is defined in ./config.yaml (OHUB_CONF). This configuration file is the source of truth that lives in the codebase and is updated only through pull requests.
This means that all the following flags / env vars should disappear:
- OHUB_SUPPORTED_OPENSHIFT_VERSIONS
- OHUB_STACK_VERSION
- OHUB_PREV_VERSION
- OHUB_TAG
- OHUB_BRANCH
It seems to me that having to adjust them is painful and above all prone to error.
hack/operatorhub/README.md
Outdated
| # If wanting to override newVersion|prevVersion|stackVersion variables in config.yaml | ||
| ./bin/operatorhub generate-manifests -c config.yaml -y ../../config/crds.yaml -y ./../config/operator.yaml -s '8.6.0' -V '2.5.0' -t '2.6.0' |
There was a problem hiding this comment.
What is the use case that would require overriding the values defined in config.yaml?
There was a problem hiding this comment.
I think I was wanting to ensure that the settings were absolutely correct when running in an automated fashion, but since the typical use case for this is to run this from a branch that already has config.yaml updated appropriately, then we can likely do without these, agreed. They've been removed.
| cd hack/operatorhub | ||
| /usr/local/bin/operatorhub generate-manifests --prev-version="$OHUB_PREV_VERSION" --stack-version="$OHUB_STACK_VERSION" --yaml-manifest=../../config/crds.yaml --yaml-manifest=../../config/operator.yaml | ||
| /usr/local/bin/operatorhub bundle generate --dir="$(pwd)" | ||
| /usr/local/bin/operatorhub bundle create-pr --dir="$(pwd)" |
There was a problem hiding this comment.
I would have kept these release commands in the pipeline and just use this script for the preflight commands.
There was a problem hiding this comment.
I figured since I was cleaning up the pipeline, I might as well keep it as clean as possible, hence moving all of this to a script. Lmk if you need me to move it back.
| cmd := &cobra.Command{ | ||
| Use: "buildkite", | ||
| Short: "Start operatorhub release operation within Buildkite", | ||
| Long: "Start operatorhub release operation within Buildkite.", |
There was a problem hiding this comment.
I think
curl -XPOST "https://api.buildkite.com/v2/organizations/elastic/pipelines/cloud-on-k8s-operator-release-operatorhub/builds" \
-H "Authorization: Bearer $BK_TOKEN" \
-d '{
"commit": "2.6.1",
"branch": "2.6"
}'could have been enough.
There was a problem hiding this comment.
We discussed this privately, and decided that opening #6408 would be beneficial.
Try and chmod the binary prior to uploading as bk artifact. Add headers to bash scripts. Silence curl. Adjust preflight command in script to actually call preflight. Use io instead of ioutil. Remove unused vars. Use http.NewRequestWithContext instead of http.NewRequest. Signed-off-by: Michael Montgomery <[email protected]>
Signed-off-by: Michael Montgomery <[email protected]>
ApiKey => APIKey per linter. README updates. Use io instead of ioutil. Signed-off-by: Michael Montgomery <[email protected]>
Co-authored-by: Thibault Richard <[email protected]>
@thbkrkr I've removed prev/stack, but removing the others is a much bigger change as, for example, tag is used throughout the tool. I'll get these removed/updated soon. |
Remove prev/stack version flags, and use values in config file. Remove need for OHUB_BRANCH. Signed-off-by: Michael Montgomery <[email protected]>
|
@thbkrkr changes made to remove need for
Unfortunately |
I think it's good to have all the configuration in the source files, so I feel like saying yes please. We already have the range in the template that we could half-generate from it or accept to have the info duplicated (we already have the minKubeVersion duplicated in the template). |
Signed-off-by: Michael Montgomery <[email protected]>
I've kept it simple, and just added it to the configuration file, and updated the validation to ensure that it exists, and is not a range. |
Signed-off-by: Michael Montgomery <[email protected]>
This reverts commit 36196b4.
Signed-off-by: Michael Montgomery <[email protected]>
Signed-off-by: Michael Montgomery <[email protected]>
This adds a Buildkite pipeline for release operations pertaining to OperatorHub/Red Hat.
This also augments our existing OpertaorHub CLI and adds new commands/sub-commands.
What's been manually tested:Full set of operatorhub release operations with aBCbuild of Operator.In progress:Currently testing Buildkite integration (will fully test during actual release).^^ All fully tested during release process for 2.6.x.